Authentication comprises the verification of the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system. (see: NIST IR 7298 Revision 1, Glossary of Key Information Security Terms.) Authorization comprises access privileges granted to a user, program, or process or the act of granting those privileges.
Representational State Transfer (REST) is a communications style that allows a client machine, for example a computer running a Web browser, to communicate to a server, for example a computer running a service. Client-server communication is “stateless” between requests, meaning each REST interaction typically contains the information for a component to understand the message. REST is considered a “lightweight” protocol suitable for distributed hypermedia systems. In the REST style, a data object is uniquely named using a Uniform Resource Identifier (URI). The REST style uses operations such as GET, PUT, POST, HEAD, and DELETE. The REST style is loosely coupled, does not require a message header, human readable, and stateless between requests. Other characteristics of REST are described in chapter 5 of the doctoral dissertation of Roy Fielding “Architectural Styles and the Design of Network-based Software Architectures,” University of California, Irvine. REST was initially described for use with Hypertext Transfer Protocol (HTTP) but is not limited to that protocol. Because REST works well for distributed, collaborative, hypermedia information systems, it has become a popular approach for supporting the World Wide Web (WWW).
REST Web services are resources accessed by users through, for example, a Web browser. RESTful Web services allow simpler application development and are ideal for interaction with Web browsers via JavaScript or AJAX. REST has become the predominant Web service design, favored by mainstream Web service providers such as Facebook, Google, and Yahoo. Information passed in a REST request is described as “front-channel” exchange.
Security Assertion Markup Language (SAML) is an XML-based standard ratified by the Organization for the Advancement of Structured Information Standards (OASIS) that defines the syntax and semantics of SAML assertions and tokens as well as protocols used to request and transmit those assertions between systems. SAML assertions can be used for exchanging authentication and authorization data from a trusted provider to a relying party. A SAML assertion comprises a package of information that supplies zero or more statements made by a SAML authority. (see: OASIS Security Assertion Markup Language (SAML) v2.0 (March 2005)) The integrity of assertions can be protected by cryptographic techniques, such as encryption of the assertion, encryption of a part of a SOAP message, use of SOAP message security, use of a SAML token, or other enveloping technique. SAML profiles describe how SAML tokens or SAML assertions can be passed by value or by reference.
SOAP, originally named for the term Simple Object Access Protocol and ratified by the World Wide Web Consortium (W3C), is a protocol for exchanging structured information. SOAP is frequently used as the messaging framework in the implementation of Web Services in computer networks. SOAP messages are XML encoded and are considered “heavyweight” comprising an envelope with a header and body therein.
OpenID® (OpenID Foundation Corp., Portland, Oreg.) is an authentication profile that provides a standardized way of authenticating a user, for example of a web browser, using credentials provided by an OpenID provider. Websites must be specifically configured to accept OpenID credentials, for example by using an authentication component that recognizes the authentication protocol. Central Authentication Service (CAS) can be used to implement authentication protocols. Users register at an OpenID provider and are provided with an identifier, typically a Uniform Resource Locator (URL). During authentication, for example to a web site, the user provides the OpenID identifier to the relying party. The relying party redirects the browser to the OpenID provider, which authenticates the user and confirms the identity of the user for the relying party.